3개월 전에 초고를 작성했었습니다. 마무리 짓지 않을 생각이었는데 디프만 14기 활동을 하면서 제 경험을 공유해야겠다는 생각이 들었습니다. 이번 디프만 14기에서 부회장으로 참여하면서 프로젝트를 진행하진 않지만, 참여하시는 팀원분들과 대화하다 보면 비슷한 고민을 하고 계신 걸 알게 되었습니다.

디프만 활동에서 얻을 수 있는 점이 무엇일까?, 성공적인 프로젝트란?, 협업을 어떻게 잘할 수 있을까?, 다른 팀(동아리)은 어떤 부분에 중점을 두고 있을까?..

저도 비슷한 고민을 했었는데 제 경험과 생각을 공유하면서 앞으로 디프만 활동하시는 분들이 더 의미 있는 시간을 보냈으면 하는 바람으로 글을 작성해 봅니다.

프로젝트 전반적인 내용이 아닌 프론트엔드 개발자로서의 경험이 더 궁금하신 분들은 마무리에 있는 “Ding Dong FE를 소개합니다”(노션 문서)를 참고해 주세요:)

기간

2023.04 ~ 2023.07, 16주간 진행한 디프만 13기에 대한 회고입니다. 디프만 13기를 통해 프론트엔드 개발자로서 협업과 기술 역량에 대한 의미 있는 고민을 할 수 있었습니다.

이 기간 동안 저의 동기와 모집 및 합격 과정, 그리고 프로젝트 회고를 통해 IT 동아리에서의 경험을 공유하고자 합니다.

동기

디프만은 개미는 툰툰, 아맞다와 같은 흥미로운 주제의 서비스와 이전 기수가 작성한 후기 글을 통해 알게 되었습니다. 특히, 후기 글과 홈페이지 소개를 읽으면서 프로젝트를 진행하며 겪은 아쉬운 부분을 해결할 수 있을 것 같았습니다.

부트캠프(코드스쿼드) 과정을 포함해, 두세 번의 프로젝트에서 두 가지 아쉬운 부분이 있었습니다. 바로 실제 사용자가 없고, 체계적인 계획이 부족한 점이었습니다. 실제 사용자가 없으니 유의미한 피드백을 받기 어려웠고, 가설을 기반으로 기능을 구현하다 보니 “사용자의 불편함을 개선”할 만 경험이 없었습니다. 또한, MVP, 애자일과 같은 개념을 알고 있었지만 프로젝트에 적용하지 못한 채로 지나갔습니다.

프로젝트에서 겪은 아쉬움과 별도로 제가 빠르게 학습하고 적용할 수 있는지 검증하고 싶은 마음도 있었습니다. 다른 사람은 어떻게 개발하고, 어떤 생각을 가지고 프로젝트를 진행하는지 알지 못하는 상황에서 제가 잘하고 있는지 늘 의구심이 들고 있었습니다. 이때, 16주라는 한정된 기간 안에 다른 사람들과 새로운 기능을 구현한다는 과정을 제가 잘하고 있는지 검증할 수 있는 좋은 기회라고 생각했습니다.

모집 및 합격

서류 및 면접 과정을 거쳐 디프만 IT 동아리에 합격했습니다. 면접에서는 지원자격뿐만 아니라 열정, 협업 능력, 커뮤니케이션 스킬과 같은 추상적인 개념을 글로 표현할 수 있는 경험이 중요한 요소로 간주되었습니다. 당연한 이야기이지만, 디프만에서 원하는 사람이 어떤 사람일까 파악하고, 제 경험을 잘 녹여내야 했습니다. 면접은 자소서 및 제출한 블로그를 기반으로 진행되었으며, 협업, 열정, 책임, 끈기에 관한 내용으로 질문이 이뤄졌습니다. 기술적인 질문도 일부 포함되었으며, 최소한의 기술 역량을 확인하고 제가 작성한 내용을 검증하는 느낌을 받았습니다.

프로젝트 회고

결론부터 말하자면 아쉬운 부분이 많았습니다. MVP, 애자일과 같은 개념을 기반으로 한 체계적인 프로세스를 적용하지 못했고, 성공적인 프로젝트라고 말하기 어려운 부분이 있었습니다. 하지만 프로젝트 결과와 별개로 16주간 디프만 활동을 통해 개발자로서 한 단계 더 성장할 수 있었습니다.

프로젝트 목표

프로젝트를 시작할 때, 저희 팀은 두 가지 가장 중요한 목표를 세웠습니다.

첫 번째 목표는 “사용자의 불편을 해소할 수 있는 서비스를 만들자”였고, 두 번째 목표는 “유지보수 및 초기 유저 유입이 어려운 커뮤니티성 서비스를 지양하자”였습니다. 그러나 16주가 지난 뒤 저희 팀은 두 가지 목표 중 어느 한 가지 목표를 이루지 못했습니다. 저희가 생각했을 때 흥미로운 아이디어를 선택했고, 커뮤니티성 서비스를 만들었습니다.

왜 이런 결과가 나왔을까 생각해 보면, 유저의 불편을 해소하자는 목표가 아닌 “이거 재밌을 것 같다!”에서 아이디어가 도출되어서가 아닐까 하는 생각이 들었습니다. 특히 저는 유저가 아닌 메이커 관점에서 “이런 재밌는 서비스를 만들면 사람들이 사용해 주겠지!”라는 생각을 했던 것 같습니다.

아이디어 검증 과정이 부족했다 (MVP)

아이디어 회의를 통해 나온 여러 아이디어 중 어떤 아이디어를 선택할까, 그 과정은 중요하지 않았습니다. 오히려 선택한 아이디어가 먹힐 것인가 검증하는 과정이 더 중요하다고 생각합니다. 아이디에이션을 하다 보면 “A는 이래서 좋고, B는 저래서 좋아”, “C라는 서비스가 이미 있는데?”, “D는 제 지인들이 재밌을 것 같다고 했어요!” 등등의 의견이 나옵니다. 이런 이야기를 듣다 보면 다 맞는 이야기라는 느낌을 받습니다. 나름의 근거가 포함되었기 때문입니다.

하지만 사용자가 있는 서비스를 만들기 위해서는 빠른 피드백과 검증이 필요했습니다. 서비스를 다 만들고 배포 이후에 피드백을 받아서 개선하기까지 시간이 많이 듭니다. 프로젝트가 끝나고 유지보수한다는 보장도 되어 있지 않습니다. 회의 시간에 MVP에 대해 논의하며 최소 기능과 가설에 관한 이야기는 자주 나왔습니다. 하지만 가설을 검증하고 테스트할 방법에 대한 논의가 부족했던 것 같습니다. “빠르게 시도하고, 빠르게 실패를 인정하라”라는 문구는 알고 있지만 “어떻게, 무엇을 시도하지?”라는 질문에 대답하지 못했습니다.

설문과 UT를 통해 사용자에게 의미 있는 피드백을 받았지만 한정된 시간 안에 짧은 피드백을 주기를 가져가기 쉽지 않았습니다. 모수가 너무 작다 보니 UT와 설문을 토대로 프로젝트의 방향성을 정해도 될지 하는 의문이 따라왔습니다. (14기를 진행하는 지금도 아이디어를 빠르게 검증하는 방법에 대한 고민은 계속하고 있습니다.)

협업과 요구사항

아이디에이션과 기획 단계에서 아쉬움이 많았지만, 개발자로서 성장할 수 있는 기회가 없었던 건 아닙니다. 학생 입장에서 10명의 팀원과 협업할 수 있는 좋은 경험이었습니다. 다른 직군의 사람들과 요구사항을 함께 분석하고 개발하는 경험도 빼놓을 수 없지만 개인적으로 가장 의미 있었던 건 리소스 투입 대비 효과를 고려해야 한다는 말을 들었을 때입니다.

제가 프로젝트를 진행하며 가장 많이 들었던 말은 “YES 맨”입니다. “단순히 안 된다고 말하는 것보다 왜 안 되는지, 어떻게 해결할 수 있는지가 중요하다”라는 말을 잘못 이해하고 모든 요구사항을 처리해야 한다고 생각했습니다. 모든 문제를 해결하는데 시간만 있다면 해결하지 못할 게 없고, 공수가 들더라도 서비스의 발전을 위한 요구사항이라면 필요하다고 생각했습니다.

물론, 시간을 많이 투자하면 어느 정도 문제는 해결할 수 있지만, 효율적인 개발이라고 할 수 없었습니다. 지나친 요구사항일 수도 있고, 문제를 해결하기 위한 적절한 방법이 아닐 수도 있었습니다. 1인분은 해야겠다는 부담감으로 어떤 일이든 일단 된다고 하고 혼자 끙끙 앓는 시간을 줄였다면 팀에 더 힘이 되지 않았을까 하는 아쉬움이 남습니다.

마무리

분명 아쉬운 부분이 있는 프로젝트지만, 팀원들과 함께 고민하고 결정하는 과정에서 인사이트가 있는 프로젝트였습니다. 개발자로서 하나의 서비스를 완성하기 위해 프로그래밍 스킬뿐만 아니라 다양한 소프트 스킬이 필요하다는 걸 느꼈습니다.

프로젝트 전반적인 경험이 아닌 프론트엔드 개발자로서 경험한 협업과 기술적인 고민은 팀원들과 함께 정리한“Ding Dong FE를 소개합니다”에서 확인하실 수 있습니다.

앞으로 제 글이 디프만에 참여하실 분들께 조금이나마 도움이 되길 바라며 글을 마무리합니다.